Are deploys still automatic on pushes to main?

Are deploys still automatic on pushes to main?

Deploys were not automatic on pushes to main. So we still trigger them here

Are deploys still automatic on pushes to main?

Deploys were not automatic on pushes to main. So we still trigger them here

That was the primary reason we had the separate branches, previously.

That was the primary reason we had the separate branches, previously.

I see. We could still change the release flow to trigger automatic release once the PR is merged into main or to trigger when it sees a new tag (if we want to accumulate all the changes and release it in a batch).

The reason to make main as the default branch is to avoid keeping two branches. Currently, when a squashed commit is created into main branch, it gets out of sync from staging branch and subsequent merge into main fails (unless we do main to staging merge).

Also, currently, the flow requires someone to locally merge commits from stating into main (without squashing) and then push to main. This could lead unnecessary changes that are not reviewed in PRs. So, it's better to have only one branch where everyone's code gets reviewed and merged.

@mvadari @Patel-Raj11
I'm not aware of what automated deployment we have or had for Explorer, but I'm thinking of having a CI/CD release pipeline that will look like this

1. Merge a PR into main
2. Pipeline triggers automatic deployment to dev environment
3. Pipeline is blocked
4. Someone clicks an approval button to manually trigger a deployment to the staging env
5. Pipeline is blocked
6. Developers perform whatever manual verifications they want/should
7. Someone clicks an approval button to manually trigger a deployment to the prod env

This way, we wouldn’t need to open PRs just to merge branches around, or manually trigger a GitHub workflow per environment (readme). We could even drop steps 3 and 4 and have every merge auto-deploy to dev and staging with no human intervention. If we want a more complete setup with rollback support, we could deploy from tags instead of deploying directly from a branch.

This PR moves us one step closer to that goal.

@mvadari @Patel-Raj11 I'm not aware of what automated deployment we have or had for Explorer, but I'm thinking of having a CI/CD release pipeline that will look like this

1. Merge a PR into main
2. Pipeline triggers automatic deployment to dev environment
3. Pipeline is blocked
4. Someone clicks an approval button to manually trigger a deployment to the staging env
5. Pipeline is blocked
6. Developers perform whatever manual verifications they want/should
7. Someone clicks an approval button to manually trigger a deployment to the prod env

This way, we wouldn’t need to open PRs just to merge branches around, or manually trigger a GitHub workflow per environment (readme). We could even drop steps 3 and 4 and have every merge auto-deploy to dev and staging with no human intervention. If we want a more complete setup with rollback support, we could deploy from tags instead of deploying directly from a branch.

This PR moves us one step closer to that goal.

Yes, that makes sense. Just wanted to make sure there wasn't an auto deploy to prod on every commit to main 🙂